Node / ReticulumProjects / MeshChatX.git / files / docs / agents / skills / page-toast-tests / SKILL.md

Displaying Rendered • View raw • Download

New MeshChatX pages with routes, nav, toasts, i18n, and tests.

Use this skill to implement feature pages in this repository without missing integration points:

• frontend route registration

• navigation exposure

• translated labels

• user feedback via T383838ToastUtils

• test coverage updates

This skill is optimized for the MeshChatX structure under T383838meshchatx/src/frontend and T383838tests/.

Before editing files, decide:

1. Is this a top-level page route or a modal/section inside an existing page?

2. Does the action require backend API work, or can it stay frontend-only?

3. Which toast types are expected on success, warning, and failure?

4. Which tests should prove behavior: frontend unit test, backend test, or both?

For a new top-level page, verify all relevant items:

• Add route in T383838meshchatx/src/frontend/main.js with T383838defineAsyncComponent.

• Add sidebar/tools entry in T383838meshchatx/src/frontend/components/App.vue when the page must be user-discoverable.

• Add translation keys in T383838meshchatx/src/frontend/locales/en.json and other maintained locale files when touched by task scope.

• Use T383838ToastUtils in page actions that save, submit, refresh, copy, or fail.

• Add or update tests in T383838tests/frontend/*.test.js.

• Add or update backend tests in T383838tests/backend/*.py if API behavior changes.

Place the component in the matching feature directory, for example:

• T383838meshchatx/src/frontend/components/tools/<NewPage>.vue

• T383838meshchatx/src/frontend/components/<feature>/<NewPage>.vue

Keep the page consistent with existing patterns:

• use translated UI text with T383838$t("...")

• use T383838window.api for API calls in page logic

• use T383838MaterialDesignIcon patterns already used in peer pages

In T383838meshchatx/src/frontend/main.js:

• add a route object with stable T383838name and T383838path

• load component via T383838defineAsyncComponent(() => import("..."))

• use T383838props: true only when path/query data is required by the component

If user navigation should expose the page:

• add a T383838SidebarLink entry in T383838meshchatx/src/frontend/components/App.vue, or

• add it in the tools area if it belongs under tools, not primary nav

Keep naming consistent between route name, i18n label, and visible button/link text.

Import from:

• T383838meshchatx/src/frontend/js/ToastUtils.js

Use:

• T383838ToastUtils.success(message) for completion

• T383838ToastUtils.error(message) for failures

• T383838ToastUtils.warning(message) for recoverable risk

• T383838ToastUtils.info(message) for neutral updates

• T383838ToastUtils.loading(message, 0, key) and T383838ToastUtils.dismiss(key) for long-running operations

Guidelines:

• prefer translated messages from locale keys over hardcoded strings

• include backend-provided error detail when safe and useful

• for progress toasts, use stable keys to avoid stacking duplicates

When adding page behavior:

• create or extend a test in T383838tests/frontend/

• mount component with T383838$t, T383838$route, T383838$router mocks

• stub non-essential child components

• mock T383838window.api responses for success and error flows

• assert both state and rendered output

• assert toast calls when operation outcomes are user-visible

When API/backend behavior is changed:

• add focused tests under T383838tests/backend/

• patch heavy dependencies and network side effects

• verify returned payload shape and error contracts expected by frontend

• keep fixture setup minimal and local to behavior under test

Only finish once these are true:

• route works and page renders from navigation path

• all user-facing strings are translated keys

• toast behavior exists for core success/failure actions

• frontend test covers key path and an error path

• backend tests are updated if API behavior changed

• no unrelated files were changed

• Follow existing file and naming conventions before introducing new patterns.

• Keep implementation incremental. Avoid broad refactors in feature delivery.

• Prefer clear user feedback over silent failures.

• Match current test style in nearby files instead of inventing a new structure.

• Trigger and output examples: examples.md